Alright, thanks!

Just a quick comparison of #13638 / this

You're currently not using QPixmapCache?

in the left screenshot it looks like the waveforms where drawn at higher resolution and then scaled down with anti-aliasing while in the right one they seem to have been drawn at screen resolution without AA?

I couldn't resist to look into the issues, so here are some commits that fix the deck overview and the scaling in OverviewDelegate:
a09a037
73edc2f

Sometimes the overview delegate only shows the first few chunks of the generated image (when it's being analyzed after loading to deck).

Update immediatly when type is changed
99d13c3

You're currently not using QPixmapCache?

Well, the idea was to have two layers of cache: One that will cache full size QImages and the other one that will cache scaled down QPixmaps with QPixmapCache. I first wanted to get the first one working properly, and only then introduce the second one.

Also, thank you for the fixes. I'll incorporate them.

Note that there are also other generic caches in Qt. QCache and QContigousCache, the latter specifically designed for caching model content (though I'm not sure how good that jives with sorting).

Note that there are also other generic caches in Qt. QCache and QContigousCache, the latter specifically designed for caching model content (though I'm not sure how good that jives with sorting).

I am using QCache for the full size QImages cache.

Well, the idea was to have two layers of cache: One that will cache full size QImages and the other one that will cache scaled down QPixmaps with QPixmapCache. I first wanted to get the first one working properly, and only then introduce the second one.

Uff, caching the raw images is costly.
I was curious how big the cache gets so I added some logging.
With the current (item) limit of 50 and after loading some overviews of live sets (1-2h) Mixxx uses ~7 GB of RAM for the QImage cache :
I fear this will cause issues on machines with little RAM, like RPi and alike.

Though this only happens during the session where a track is being analyzed.
In later sessions all track's images are ~3820 kB
What could be the reason?

This is the logging commit (yes, it's a bit excessive and slows down the GUI :\ )
f79ad80

Are these LRU caches that we can cap so they don't grow without limit?

@ronso0 I tried your commit and it seems like there is a memory leak, but I was not able to find it.

@ywwg Yes, QCache is a LRU cache and currently it is capped at 50 items.

Compared to QPixmapCache, only QCache items can be capped, but not the size.

To me it didn't look like a memory leak, it's really just the cached images that are huge. (same for the QImages created by WOverview btw)
There must a difference between rendering the image with the initial analysis data and with the reloaded (compressed?) data later on.
I'd try re-rendering when the analysis has finished.

@ninomp is there specific help / feedback you're looking for? I would love to help push this feature forward